Add Feature Documentation #154
Conversation
|
alright, it looks good from my perspective, however there's one more thing that could be done if you want. |
CONTRIBUTING.md
Outdated
| - [ ] Decide what, if any, state is required for your feature (caret position, last focused item, etc.) | ||
| - For example: to know if the current window is focused, the current window must be stored in the state of the screen reader. | ||
| - [ ] Check to see if we already have your state info as a type; you can check this at `odilia/src/state.rs`. | ||
| - If not, make a [newtype](https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction), add it to the `State` struct, then implement the `FromAsyncState` trait for the type (so it can be extracted by the `FromAsyncState` implementation). |
There was a problem hiding this comment.
I wonder if it wouldn't be better, from a document-source-reading perspective, if this URL were a named reference? You'd change the link here to something like,
[newtype][newtype-pat]And waay at the bottom of the file, drop in:
[newtype-pat]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
There was a problem hiding this comment.
hmm, that's debatable, as most people would read it in rendered form anyway. Definitely could be done though, if @TTWNO thinks it's better that way. If you read the markdown source though, it's definitely better to do it the way you suggest
TTWNO
force-pushed
the
add-feature-documentation
branch
from
f27fd22
to
2d93e64
Compare
Fix #153